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ABSTRACT 

The Single Stage Rocket Technology (SSRT) Delta Clipper Experimental (DC-X) 
Program is a United States Air Force Ballistic Missile Defense Organization (BMDO) 
rapid prototyping initiative that is currently demonstrating technology readiness for 
reusable suborbital rockets. The McDonnell Douglas DC-X rocket performed technology 
demonstrations at the U.S Army White Sands Missile Range in New Mexico from April- 
October in 1993. 

The DC-X Flight Operations Control Center (FOCC) contains the ground control system 
that is used to monitor and control the DC-X vehicle and its' Ground Support Systems 
(GSS). The FOCC is operated by a flight crew of 3 operators. Two operators manage 
the DC-X Flight Systems and one operator is the Ground Systems Manager. 

A group from McDonnell Douglas Aerospace at KSC developed the DC-X ground 
control system for the FOCC. This system is known as the Real Time Data System 
(RTDS). 

The RTDS is a distributed real time control and monitoring system that utilizes the latest 
available COTS computer technology. The RTDS contains front end interfaces for the 
DC-X RF uplink/downlink and fiber optic interfaces to the GSS equipment. The FOCC 
operators run applications on the RTDS Unix workstations. Twenty one customized 
SSRT applications were developed for the FOCC RTDS. The application design was 
based on the programs "aircraft like" operability requirements. 

The paper will contain descriptions of the RTDS architecture and FOCC layout. Detailed 
information on the 21 DC-X applications will be included. A section will include the DC- 
X ground operation philosophies and rapid prototyping techniques. The paper will 
describe the DC-X ground operations performed in the FOCC. 
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1. SSRT Introduction 


McDonnell Douglas Space Systems Company, of Huntington Beach, California was 
awarded the $58.9 mtlhon Single Stage Rocket Technology Program contract to 
demonstrate single-stage rocket technology (SSRT) on the Delta Clipper Experimental 
vehicle or DC-X, in August 1991. The DC-X is a Ballistic Missile Defense Organization 
( ormerly the Strategic Defense Initiative Organization) rapid prototyping initiative that is 
demonstrating the technology readiness of SSRT. The DC-X, designed for vertical 
takeoff and landing, is an operational one-third scale experimental test vehicle of an actual 
reusable launch system. The reusable vehicle is propelled by liquid oxygen/liquid 

engmes ' A full-scale Delta Clipper, the DC-Y, will be capable of placing 
a 20,000-lb payload into low-earth orbit. 6 


2. SSRT Real-Time Data System 

data SyStem ( RTDS ) was developed by the Kennedy Space Center division 
of McDonnell Douglas to meet the DC-X requirements for an advanced launch processing 
system that provided "aircraft-like" capabilities. The RTDS provided the ground 
monitoring, control, and data archival/reduction capabilities for the DC-X vehicle and its 
ground support systems (GSS). The RTDS was located at the White Sands Missile Range 
in the mobile DC-X ground operations base, a 40-foot trailer known as the Flight 
Operations Control Center (FOCC). 

This paper presents a view of the DC-X program, then relates the RTDS to the program 
and explains how the DC-X team was able to do its work quickly, cheaply and 

OllPr'OCC'rt lllxr J 7 


3. DC-X Program Summary 

The DC-X is a rapid prototyping initiative that enabled the vehicle to be designed built 
and flown in two years. A highly motivated team of McDonnell Douglas employee’s from 
the company's Huntington Beach, Long Beach, St. Louis, and Kennedy Space Center 
divisions teamed with subcontractors from across the nation to design, build, and integrate 
the DC-X vehicle in 18 months. The vehicle was shipped to the NASA White Sands Test 
Facility in New Mexico in April 1993 for a series of static fire tests. The tests were 
successfully completed in June and the DC-X vehicle and its entire ground support system 

were packed and shipped to the flight test site at the U S. Army White Sands Missile 
Range. 


Two static fire tests were conducted at White Sands to verify system operation after the 
move from the test facility. These full-system tests were conducted successfully and the 
vehicle was prepared for flight. The first flight of the DC-X, a 60-second, 150-foot hover 
test to verify the operation of flight systems, was made August 1 8, 1 993 at the White 
Sands Delta Clipper site. Two additional test flights, conducted at higher altitudes, with 
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increased pitch and roll maneuvers, were completed successfully on September 11th & 
September 30th. These tests demonstrated the following DC-X goals: 

• Validate vertical takeoff and landing concepts 

• Validate "aircraft-like" supportability and maintainability concepts 

• Demonstrate rapid prototyping development approach 

• Demonstrate rapid turnaround capabilities 

Funding for the program was depleted at the end of October 1993, and the DC-X 
remained mothballed at White Sands awaiting additional funding. This Finding was 
received in early May of 1994. The flight test program has completed two flights on June 
20th and 27th of 1994. Additional DC-X flights which continue to expand the DC-X 
flight envelope and demonstrate the operability characteristics are planned in 1994. 


4. DC-X - New Ways of Doing Things 

The primary goal of the SSRT program is to provide inexpensive access to space into the 
next century to give this nation a low-cost advantage in space transportation. To meet 
this goal, the DC-X had to do things better, faster, and cheaper. 

Rapid prototyping technologies were used extensively to allow the development team to 
complete the job on schedule. Automatic code-generating software aided in the rapid 
development of DC-X flight software, allowing the flight software to be changed and 
validated in hours instead of many days. Use of off-the-shelf technology with open system 
architecture was maximized throughout the program. The off-the-shelf products reduced 
development time while providing many of the necessary capabilities at much lower risk 
and costs. 

The off-the-shelf products used extensively in the development of the RTDS for the 
FOCC included: 

• UNIX system V 

• ISO SC 16 open systems interconnection protocol 

• IEEE 802 network standards (includes Ethernet) 

• DARPA TCP/IP networking protocol 

• C-ISAM data structure 

• ANSI X3. 135-1986 SQL database interface 

. IEEE 1014 (VME) bus interface 

• IEEE 754 floating point number standard 

The DC-X also took a new approach to operation of launch vehicles. The entire DC-X 
system was designed with aircraft-like operability and maintainability concepts. 
McDonnell Aircraft applied its experience in military aircraft design to develop the 
avionics systems for the DC-X vehicle, providing easy access to line-replaceable avionics 
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units from access bays, similar to aircraft. The avionics systems were designed with built- 
in test features and automated modes that allow for rapid checkout of the vehicle 
subsystems. Douglas Aircraft applied its experience in developing commercial aircraft 
supportability and maintainability features to help design these critical elements into the 
DC-X operating procedures. Douglas also contributed expertise from commercial aircraft 
cockpit controls and displays technology. Several of the commercial aircraft concepts 
were designed into the RTDS ground control system human-computer interfaces. 


The RTDS was designed with many automated features that allowed the DC-X and GSS 
to be controlled and monitored with a crew of only three. The system was delivered and 
installed before the vehicle assembly was completed. This allowed the RTDS to be 
integrated and validated with vehicle subsystems as they were assembled and attached to 
the core vehicle structure. The parallel checkout of the RTDS interfaces with the actual 

TES/T* aSSemWy a " 0Wed for many reaMime modifications and enhancements to 
the RTDS human-computer interfaces before the vehicle assembly was completed. The 

e ective use of off-the-shelf software development packages allowed the RTDS changes 
to be made rapidly while integrating the vehicle components. This parallel effort allowed 
the entire vehicle and ground system to be folly integrated and ready for the static fire tests 
at White Sands on the same day that the vehicle completed final assembly. 

The DC-X and GSS components and systems were all checked out with the same RTDS 
c eckout system, which was also used for the integration component tests during vehicle 
assembly, avionics subsystem verifications, engine static fire tests, and the entire flight test 

SPDPC & ' 


The reusability capabilities of the DC-X vehicle along with the new operability 
maintainability, and supportability concepts have allowed the entire DC-X program to be 
conducted by approximately 35 persons. Thus, the DC-X has proved that low-cost 
programs are possible - today and for the future. 

5. Real-Time Data System Background 

The DC-X required a state-of-the-art automated ground control system that could 
implement customized real-time user monitoring and control interfaces, provide 
automated sequences and automatic reactive control functions, and contain capabilities for 
archiving, retrieving, and reducing flight test data. This system would have to be 
designed, developed, validated, and delivered within 10 months. The Kennedy Space 
Center division of McDonnell Douglas was asked to develop this ground control system 
because of its experience in this area. The RTDS was subsequently developed by the 
division's Automated Checkout Systems department based on a system it designed for 
space shuttle payload checkout, which is still in use. This baseline system, the partial 

payload checkout unit (PPCU), has been used in the Operations and Checkout Building at 
KSC since 1990. & 


158 



PPCU is a generic, real-time data monitor and control system with front-end and back-end 
interface extensions and a distributed network of data processing and recording 
equipment. PPCU utilizes highly modular subsystems, industry standards, and commercial 
software and hardware, where practical, to provide a reliable, flexible, and continuously 
upgradable system at minimal cost. 

6. Ground Systems Layout 

The FOCC primarily consists of the equipment housed in a van and external interfaces to 
the DC-X vehicle GSS. The boundaries of the FOCC are illustrated in Figure 1 . 

The RTDS, the primary subsystem of the FOCC, serves as the operator interface for real- 
time monitor and control of both the DC-X vehicle and the GSS. 



VANS 


Figure 1. The Flight Operations Control Center 
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7. RTDS Architecture 


The RTDS processing elements provide for monitoring and displaying real-time data. The 
recording elements provide independent real-time data recording. The architecture is 
implemented as shown in Figure 2 and consists of five major subsystems connected via 

Ethernet networks. Each subsystem consists of one or more processors in parallel or in 
clusters. 



Figure 2. RTDS Architecture 


Data Acquisition Modules 

The interface from the RTDS to the DC-X vehicle and GSS is composed of a data 
acquisition subsystem that operates in an autonomous fashion. The subsystem features 
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three data acquisition modules connected to a data acquisition processor for data 
concentration. Each module is configured with hardware and software to preprocess a 
dedicated data link. The RTDS contains three data acquisition modules: telemetry 

downlink, telemetry uplink, and ground support equipment (GSE). For DC-X, these three 
modules' front-end interfaces are PCM telemetry downlink, RF RS-422 uplink, and GSE 
RS-232. They interface with fiber optic modems that connect the commercial remote 
interface modules (CRIMs) at the launchpad to the RTDS GSE data acquisiton modules in 
the FOCC. This generic RTDS subsystem architecture provides flexibility to incorporate 
additional interface types in the future by simply adding an additional module to the data 
acquisition subsystem bus network in the RTDS. 

Subsystem preprocessing consists of all the interface and data-dependent operations 
required to provide normalized, time-tagged data to the RTDS. The raw data from the 
vehicle and GSS is passed through a data acquisition module data filter. Each sample is 
compared with the last sample that changed significantly. If a significant change of value 
has occurred, then the new sample value is processed. Limit-checks are performed on the 
processed data in order to detect measurements that have violated any upper or lower 
limiting conditions. After limit-checking, the processed data is distributed throughout the 
rest of the system. 

Commercial Remote Interface Module 

The RTDS has a GRIM located on each side of the DC-X flight stand. The CRIM is a 
VME chassis that contains a microcontroller card and several discrete and analog 
input/output cards. The CRIM continuously monitors the analog and discrete status of the 
GSS equipment and sends the status back to the RTDS GSE data acquisition module. 
Commands from the RTDS GSE modules are received over the RS-232 communication 
lines and the appropriate analog and discrete channels are activated upon their receipt. 
Vehicle electrical power is also controlled through the CRIM. 

Data Acquisition Processor 

The concentrator in the data acquisition processor combines the data outputs from the 
modules into an integrated data stream broadcast to the other RTDS subsystems. The 
processor also receives system commands and end-item commands and routes them to the 
appropriate modules. Once loaded and initialized, the subsystem broadcasts data to the 
data acquisition processor for use by the application processor and the archive and 
retrieval subsystem. 

Application Processor 

The application processor is the RTDS real-time data processing element and provides for 
execution of the customized DC-X user application programs. It broadcasts measurement 
data to the display processors and processes commands from the users originating at the 
display processor. Commands issued from user applications are routed through a 
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command distribution manager on the application processor which verifies user 
permissions prior to issuing and routing commands to their proper destinations. All 
commands are recorded for posttest retrieval. 

Archival and Retrieval Subsystem 

The archival and retrieval subsystem contains the recording elements within the RTDS 
system. This subsystem records the digitized raw telemetry stream, as well as the 
processed telemetry and GSE data. Data are recorded to hard disk to support near-real- 
time retrieval of the vehicle and GSS information. Data can be retrieved and plotted in 
minutes using the hard disk-archived information. The data are also recorded on 4mm 
tape for the historical posttest retrieval archives. RTDS subsystem health, end-item 
commands, user "mouse" selections, and system messages are also recorded by the 
archival and retrieval subsystem. 

Display Processors 

Four color graphics workstations called display processors provide the user interface to 
control and monitor the DC-X vehicle and GSS. Operators send commands by a mouse 
and use the display processor multiwindow graphics capability to configure the system to 
their specific needs. The windows environment is an X-Windows-based system; that is, it 
is implemented with off-the-shelf software tools to allow a continual upgrade path to 
future releases of hardware and software. The user interface is capable of being logically 
configured, based upon the user permission level, to support a range of capability from 
system configuration and monitor-only permissions to total control and monitoring 
permissions. 

Database Subsystem 

The database subsystem contains the RTDS data retrieval processing, configuration 
management utilities, and the RTDS generic measurement and command database. RTDS 
front-end interfaces and command data formats are defined in this generic database. The 
RTDS operator updates the telemetry uplink, and downlink, and GSE measurement and 
command information in the generic database using customized database forms. The 
subsystem then builds generic real-time tables for each of the RTDS subsystems. This 
generic database structure allowed for near-real-time modifications to the DC-X 
measurement and command information. This feature was critical in meeting the rapid 
pace of the DC-X program, where sensors were being added and modified continually. 

The generic format of the RTDS allows the system to contain multiple formats and 
provides the flexibility to easily support new systems in the future. New launch systems 
could be supported simply by defining the front-end telemetry and GSE information in the 
database and developing the customized user interface applications. 

8. RTDS Human-Computer Interface 
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The DC-X ground operations procedures were developed using "aircraft-like" concepts to 
reduce ground operator workload. The RTDS was designed to allow a crew of only three 
operators to perform all the activities required for the DC-X preflight, flight, and 
postflight operations. Two operators, the flight manager and deputy flight manager, are 
assigned DC-X vehicle monitoring and control functions similar to pilot and co-pilot 
functions, while the third operator performs the duties of the ground systems manager. 

Twenty-one customized applications were developed for the DC-X and its GSS as listed 
below: 

Ground Support Systems (7) 

• GSS propellant safing and master controls 

• Liquid hydrogen 

• Liquid oxygen 

• Gaseous hydrogen 

• Gaseous oxygen 

• Gaseous nitrogen 

• Gaseous helium 
Vehicle Subsystems (9) 

® Flight sequencer controls 

• Vehicle hydraulics 

® Vehicle main engines 

• Vehicle reaction control system 
® Vehicle propulsion system 

• Vehicle avionics 

• Vehicle rate/accelerometer sensors and radar altimeter 

• Vehicle electrical system 

• Flight constants 
Flight Displays (2) 

• Flight profile 

• Flight subsystem monitoring 
RTDS Administration 

• Pseudo measurement initialization 
« Data acquisition module controls 

• GSE-CRIM automated checkout 

The RTDS applications were designed with many automated sequences and graphical 
monitoring features. The user interfaces maximize the DC-X operability features and keep 
the operator workload to a minimum. Electronic checklists record preflight steps to allow 
the operator to avoid use of paper manuals. Application displays are schematics of the 
actual GSS and DC-X vehicle subsystems to allow for rapid assessment of subsystem 
status and configuration. The displays rely heavily on the effective use of color coding, 
alarms, and positional dynamics to give the user both graphical and numerical 
representations of the vehicle and GSS information. 


163 



Ground Support Systems 


The GSS contains seven applications for loading propellants and gases in the vehicle The 
tour gases have automatic topping modes that key off temperatures and pressures to 
control their flow The liquid propellants have automated purging and loading sequences, 
e loading procedures monitor tank-level sensors to control the flow of the liquid oxygen 

an hydrogen. Automatic and manual sating features ensure that the vehicle can be 
quickly safed in the event of fires or leaks. 

Vehicle Systems 

The flight sequencer application contains the electronic checklist and controls to sequence 
through the 18 automated vehicle modes. The flight manager used this application to 
monitor events as the automated vehicle modes were commanded. The application has 
several screens that change as the flight manager commands the vehicle through its 
preflight built-in-tests and simulated flight modes. The deputy flight manager used the 
various subsystem screens to monitor the status of the built-in test equipment and 
subsystems throughout the preflight sequence. 

Flight Screens 

Two screens were developed to monitor the DC-X flight. The flight profile monitors the 
vehicle profile latitude/longitude positions, altitude, and the pitch, roll, yaw information. 

e vehicle subsystem momtor displays engine performance graphs, propulsion, hydraulic 
landing gear, flap, and engine gimballing status. 

Figures 1-4 contain black and white copies of four actual DC-X RTDS displays. 

9. Conclusions 


The DC-X program has proven that things can be accomplished quickly and cost- 
effectively by following a "build a little, test a little" rapid prototyping philosophy. The 
rapid prototyping technology was effective on this program, and could be used in the 
future as a means of achieving better, faster, and cheaper development. 

The next step is to continue our "build a little, test a little" philosophy and move onto the 
two-third scale prototype known as the SX-2. This vehicle will be capable of higher 
altitude flight, higher velocities, and have greater maneuverability. The SX-2 will start to 
prototype and test lightweight material technology that will be required for the ultimate 
success of the full-scale single-stage-to-orbit vehicle known as the DC-Y. 
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FIGURE 3 - 1-IQUID HYDROGEN GROUND SUPPORT EQUIPMENT 
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FIGURE 4 - DC-X VEHICLE SUBSYSTEM FLIGHT MONITORING 
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FIGURE 5 - DC-X FLIGHT PROFILE MONITORING 
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FIGURE 6 - DC-X PREFLIGHT MODE SEQUENCER 
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